\section*{Paper Prototypes}
The SharingBooks team presented a UI that strived to be easy to
learn. All the buttons and boxes were clearly labeled and using the
product was meant to be easy overall. The only problem was that the UI
was hard to learn for first-time users, or at least it was in our
experience. For instance, we had trouble figuring out what to do after
finding a book or wanting to trade a book during a use case. This
frustrating problem was only exacerbated by things like the clutter of
many tabs during some of the use cases.

Also, the UI was not very easy to use. There was one major problem
where a user was only able to use one feature of the UI at a
time. That means that if you were to use the ``find books'' feature,
you would not be able to view the library at the same time. You would
have to close the find books and then go view your library, but you
would then have to go through ``find books'' feature again to get to
where you were which seemed redundant.

As mentioned above, the presented UI was not particularly efficient at
performing tasks quickly. An example is if you went to sell or trade a
book and you have to decide on the price you want to sell it for. One
basic instinct is to do a search and look for current prices and
undercut the market. However, in this application, you would have to
close the sell/trade book feature, open the ``find books'' feature,
look for the book, remember the price, navigate your way back to the
sell/trade feature, and then finally input a price. This leaves the
user yearning for a better way, a better way future iterations of the
UI should provide.

However, the application was built with familiar constructs such as
search boxes and tabs. Not only that, it uses the Facebook API so it
has a Facebook feel to it which a lot of people feel comfortable
with. This helps the UI make up some of its lost learnability.

The prototype allowed for the completion of all the use cases and
during the use cases, we were able to accidentally complete other use
cases. During the testing, we didn't encounter many error cases, so
not a lot of error handling was done. However, there was a case where
a book wasn't found in the database. The solution was simple: just add
it manually or notify someone.

Overall the paper prototype was well thought out and had a lot of the
features they promised. Of course, the prototype did have the problems
listed above where it was annoying to go from one feature to another,
but besides that, everything was good. They even asked a lot of
questions during the prototyping for feedback, a sign for many better
things to come in the future.

\begin{comment}
Questions:
 - Was the UI:
   - quickly learnable?
   - easy to use?
   - clean and well-presented? (not counting that it's paper)
   - efficient on performing tasks quickly?
   - designed with familiar constructs for laymen?
   - designed well overall?
 - Did the prototypes allow for the completion of each use case?
 - Was error resolution handled well?
\end{comment}